前言

前一篇提到 Kubernetes 在應對 Microservices 時有不足之處，而 Service Mesh 能幫助我們解決，那到底 Service Mesh 是什麼，本篇就來跟大家介紹。

什麼是 Service Mesh?

對於不了解 Service Mesh 的人，可能會以為它是取代 Kubernetes 的工具，這其實是個大誤解。事實上可以把 Service Mesh 理解為 Kubernetes 的擴充套件，安裝 Service Mesh 方案到 Kubernetes 後，就能強化叢集的流量管理能力、可觀測性以及安全性。

完整的介紹可以參考 The Istio service mesh，簡單來說，Service Mesh 是一個負責處理服務之間溝通的層級，能在不修改程式的前提下直接安裝。

Service Mesh 與 Microservices 之關係

現今軟體開發架構以 Microservices 為主流，其特色就是一套系統會由許多互相溝通的元件所組成。在 Kubenetes 世界中，每個元件會以 Pod 進行部屬，隨著專案越來越複雜，Pod 數量會越來越多。因 Kubernetes 不會追蹤 Pod 的溝通行為，若其中一個元件出狀況，往往都須花費不少時間才能找到問題。

Kubernetes 無法清楚觀測 Pod 之間的溝通狀況(圖中箭頭)，也不好管理 Pod 的溝通行為

安裝完 Service Mesh 後，Kubernetes 多了一層負責處理服務溝通的層級，Pod 之間的請求皆需通過此層，透過集中化管理，就能蒐集 Pod 的連結情形，或是設置 Pod 之間的路由規則，使其在不修改服務的情況也能達到流量管理、可觀測性等功能。

Service Mesh 抽象出一個層級，不僅能紀錄 Pod 之間溝通情況，也能管理 Pod 的溝通行為

Service Mesh 原理

Sidecar(邊車)

目前 Service Mesh 有好幾種實作方式，其中最受歡迎的就是 Sidecar 模式，如同加裝到機車上的「邊車」，在此模式中，邊車會附加到主程式上，並為主程式提供支援。Service Mesh 實作上，每個 Pod 上除了應用程式的 Container 之外，還會附加一個 Proxy Container，主程式對外的請求，都會由此 Proxy 來代理，藉此就能記錄每次請求，也能管理進出的封包。

在每個 Pod 上，都會依附一個 Sidecar 來代理服務的請求

Control Plane & Data Plane

網路術語中，會聽到 Control Plane 及 Data Plane 兩個名詞，Control Plane 就像一顆大腦，負責完整規劃，而 Data Plane 如同我們的四肢，實際執行任務。Service Mesh 實作上，需要建立一個管理中心(Control Plane)，並搭配依附在每個 Pod 上的 Sidecar (Data Plane)，只需對管理中心下指令，Control Plane 就會將規則送至 Data Plane，讓 Proxy 負責執行，藉以達成實際管理行為。

圖片取至 https://www.nginx.com/blog/what-is-a-service-mesh/

總結

市面上現在有很多 Service Mesh 的解決方案，如 Linkerd、Cilium 以及 Istio，而 Istio 是現在最受歡迎的 Service Mesh 軟體，至於 Istio 的細節，我們就下一篇來說明。